fix: handle counterparty channel closes#806
fix: handle counterparty channel closes#806ovitrif merged 32 commits intofix/reimport-channel-monitorfrom
Conversation
jvsena42
changed the base branch from
master
to
fix/reimport-channel-monitor
Can also use the staging bot |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
| walletRepo.balanceState, | ||
| transferRepo.forceCloseRemainingDuration, | ||
| ) { balanceState, remainingDuration -> | ||
| val defaultTitle = context.getString(R.string.lightning__transfer_in_progress) |
There was a problem hiding this comment.
nit: can be lifted out of combine (before it) so it doesn't have to recompute with each collection.
although I think there is close to zero perf impact, the resource values are probably cached/ lazy-loaded.
| ) { balanceState, remainingDuration -> | ||
| val defaultTitle = context.getString(R.string.lightning__transfer_in_progress) | ||
| val savingsTitle = remainingDuration?.let { | ||
| context.getString(R.string.lightning__transfer_ready_in, it) |
There was a problem hiding this comment.
noop: nice, maybe we should slowly transition to the builtin parametrization standards, makes our agent's job easier.
| } | ||
|
|
||
| private suspend fun createTransferForCounterpartyClose(channelId: String, isForceClose: Boolean) { | ||
| val transferType = if (isForceClose) TransferType.FORCE_CLOSE else TransferType.COOP_CLOSE |
There was a problem hiding this comment.
nit: could've been the type of the 2nd param in the tuple/pair returned by classifyClosureReason, ie: Pair<Boolean, TransferType>
| } | ||
|
|
||
| // TODO Temporary fix while these schemes can't be decoded https://github.com/synonymdev/bitkit-core/issues/70 | ||
| @Suppress("SpellCheckingInspection") |
There was a problem hiding this comment.
nit: my IDE was highlighting the string value passed to the regex ctors from the replace chain 🥲
3 participants
Closes #802 (comment)
This PR:
syncTransferStatesto handle batched force-close sweeps correctlyDescription
ClosureReasonvariants to detect counterparty-initiated closes (force close vs cooperative)PendingSweepBalanceextension functions for extracting channel IDs and spending txidssyncTransferStates: checks on-chain activity for the channel, falls back to pending sweep status, and handles batched sweeps where LDK links a single transaction to multiple channelsCoreService.ActivityServicefor querying on-chain activity by channel or txidPreview
coop-close.webm
counterparty-coop-close.webm
conterparty-force-close.webm
force-close-settle.webm
The timestamps didn't change because of a bug caused by fast mining 146 blocks
DataException: confirm_timestamp must be greater than or equal to timestampQA Notes
for counterparty closing use the slack command
/regtest-ln-close-channel <fundingTx:vout> [force]Counterparty force close detection
** Counterparty cooperative close detection**
Cooperative close detection